We are migrating the bug tracker to github Issues. This is now the preferred way to report NASM bugs.
Self-registration is disabled due to spam issue (mail gorcunov@gmail.com or hpa@zytor.com to create an account)
$ cat test.asm cpu 8086 mov fs, ax %ifdef ERROR mov eax, 1 %endif $ nasm -v NASM version 2.15rc0 compiled on Nov 22 2019 $ nasm test.asm $ nasm test.asm -DERROR test.asm:4: error: no instruction for this cpu level $ oldnasm -v NASM version 2.12.02 compiled on Aug 10 2019 $ oldnasm test.asm $ oldnasm test.asm -DERROR test.asm:4: error: no instruction for this cpu level $
Created attachment 411803 [details] Reject fs/gs/a32/o32 as opcode prefixes on CPUs older than the 386 I can confirm. Also neither do fs/gs as standalone opcode prefixes, fs/gs in memory references nor a32/o32 prefixes (I suppose a16/o16 are fine, since they are empty anyway). Attached is a small patch for the latter problem; it doesn’t solve the original bug. Also, it gets the job done, but doesn’t result in very good error messages.
Concerning o32 and a32 I just suspected I may have depended on that being allowed under cpu 8086 in my application (86-DOS debugger). Looking it up it turns out half and half; my default build does not seem to exploit this. All the o32/a32 prefixes end up going through the _386 mmacro defined in https://hg.ulukai.org/ecm/ldebug/file/f46d3b89dbc9/source/debug.mac#l674 which already uses [cpu 386] around the instructions/prefixes it writes. Example use: https://hg.ulukai.org/ecm/ldebug/file/f46d3b89dbc9/source/run.asm#l72 However, when I enabled the alternative macro set later named _WPT_LABELS, I did depend on the bare o32 and a32 being allowed in cpu 8086 parts. Source reference: https://hg.ulukai.org/ecm/ldebug/file/f46d3b89dbc9/source/debug.mac#l565 I'm certain that NASM in recent years allowed this because I had that option def enabled as recently as 2019 May during development of the data-code-split branch https://hg.ulukai.org/ecm/ldebug/rev/cb7c43f37390 However, it would not be difficult to adjust this to also always surround the offending prefixes with [cpu 386] directives. _WPT_LABELS is severely slower than the alternative anyway, so it doesn't matter to make it yet a bit slower.